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Executive Summary 


200 Cyber attacks have increased in frequency and sophistication, resulting in significant challenges for 

201 organizations in defending their data and systems from capable threat actors (“actors”)- These actors 

202 range from individual, autonomous attackers to well-resourced groups operating in a coordinated manner 

203 as part of a criminal enterprise or on behalf of a nation-state. These actors can be persistent, motivated, 

204 and agile, and they employ a variety of tactics, techniques, and procedures (TTPs) to compromise 

205 systems, disrupt services, commit financial fraud, and expose or steal intellectual property and other 

206 sensitive information. Given the risks these threats present, it is increasingly important that organizations 

207 share cyber threat information and use it to improve their cyber defenses. 

208 Cyber threat information is any information that can help an organization identify, assess, monitor, and 

209 respond to cyber threats. Examples of cyber threat information include indicators (system artifacts or 

210 observables associated with an attack), TTPs, security alerts, threat intelligence reports, and 

211 recommended security tool configurations. Most organizations already produce multiple types of cyber 

212 threat information that are available to share internally as part of their information technology and 

213 security operations efforts. 

214 Through the exchange of cyber threat information with other sharing community participants, 

215 organizations can leverage the collective knowledge, experience, and capabilities of a sharing community 

216 to gain a more complete understanding of the threats they may face. Using this knowledge, an 

217 organization can make threat-informed decisions regarding defensive capabilities, threat detection 

218 techniques, and mitigation strategies. By correlating and analyzing cyber threat information from multiple 

219 sources, an organization can enrich existing information and make it more actionable. This enrichment 

220 may be achieved by independently confirming the observations of other community members, and by 

221 improving the overall quality of the threat information through the reduction of ambiguity and errors. 

222 Members of a sharing community who receive information and subsequently remediate a threat also 

223 confer a degree of protection to other community members (even those who may not have received or 

224 acted upon the cyber threat information) by impeding the threat’s ability to spread. Additionally, sharing 

225 of cyber threat information allows organizations to better detect campaigns that target particular industry 

226 sectors, business entities, or institutions. 

227 This publication assists organizations in establishing and participating in cyber threat information sharing 

228 relationships. The publication describes the benefits and challenges of sharing, clarifies the importance of 

229 trust, and introduces specific data handling considerations. The goal of the publication is to provide 

230 guidelines that improve cybersecurity operations and risk management activities through safe and 

231 effective information sharing practices, and that help organizations plan, implement, and maintain 

232 information sharing. 

233 NIST encourages greater sharing of cyber threat information among organizations, both acquiring threat 

234 information from other organizations and providing internally-generated threat information to other 

235 organizations. Implementing the following recommendations enables organizations to make more 

236 efficient and effective use of information sharing capabilities. 

237 Establish information sharing goals and objectives that support business processes and security 

238 policies. 

239 An organization’s information sharing goals and objectives should advance its overall cybersecurity 

240 strategy and help an organization more effectively manage cyber-related risk. An organization should use 

241 the combined knowledge and experience of its own personnel and others, such as members of cyber threat 
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242 information sharing organizations, to share threat information while operating in accordance with its 

243 security, privacy, regulatory, and legal compliance requirements. 

244 Identify existing internal sources of cyber threat information. 

245 Organizations should identify the threat information they currently collect, analyze, and store. As part of 

246 the inventory process, organizations should determine how the information is used. This inventory can 

247 help an organization identify opportunities for improving decision-making processes through the use of 

248 cyber threat information, develop strategies for acquiring threat information from alternative (possibly 

249 external) sources or through the deployment of additional tools or sensors, and identify threat information 

250 that is available for sharing with outside parties. 

251 Specify the scope of information sharing activities. 

252 The breadth of an organization’s information sharing activities should be consistent with its resources, 

253 abilities, and objectives. Information sharing efforts should be focused on activities that provide the 

254 greatest value to an organization and its sharing partners. The scoping activity should identify types of 

255 information that an organization’s key stakeholders authorize for sharing, the circumstances under which 

256 sharing of this information is permitted, and those with whom the information can and should be shared. 

257 Establish information sharing rules. 

258 Sharing rules are intended to control the publication and distribution of threat information, and 

259 consequently help to prevent the dissemination of information that, if improperly disclosed, may have 

260 adverse consequences for an organization, its customers, or its business partners. Information sharing 

261 rules should take into consideration the trustworthiness of the recipient, the sensitivity of the shared 

262 information, and the potential impact of sharing (or not sharing) specific types of information. 

263 Join and participate in information sharing efforts. 

264 An organization should identify and participate in sharing activities that complement its existing threat 

265 information capabilities. An organization may need to participate in multiple information sharing forums 

266 to meet its operational needs. Organizations should consider public and private sharing communities, 

267 government repositories, commercial cyber threat intelligence feeds, and open sources such as public 

268 websites, blogs, and data feeds. 

269 Actively seek to enrich indicators by providing additional context, corrections, or suggested 

270 improvements. 

271 When possible, organizations should produce metadata that provides context for each indicator that is 

272 generated, describing how it is to be used and interpreted and how it relates to other indicators. 

273 Additionally, sharing processes should include mechanisms for publishing indicators, updating indicators 

274 and associated metadata, and retracting submissions that are incorrect or perhaps inadvertently shared. 

275 Such feedback plays an important role in the enrichment, maturation, and quality of the indicators shared 

276 within a community. 

277 Use secure, automated mechanisms to publish, consume, analyze, and act upon cyber threat 

278 information. 

279 The use of standardized data formats and transport protocols to share cyber threat information makes it 

280 easier to automate threat information processing. The use of automation enables cyber threat information 

281 to be rapidly shared, transformed, enriched, and analyzed with less need for manual intervention. 
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282 Proactively establish cyber threat sharing agreements. 

283 Rather than attempting to establish sharing agreements during an active cyber incident, organizations 

284 should plan ahead and put such agreements in place before incidents occur. Such advanced planning helps 

285 ensure that participating organizations understand their roles, responsibilities, and information handling 

286 requirements. 

287 Protect the security and privacy of sensitive cyber threat information. 

288 Sensitive information such as personally identifiable information (PII), intellectual property, and trade 

289 secrets may be encountered when handling cyber threat information. The improper disclosure of such 

290 information could cause financial loss; violate laws, regulations, and contracts; be cause for legal action; 

291 or damage an organization’s reputation. Accordingly, organizations should implement the necessary 

292 security and privacy controls and handling procedures to protect this information from unauthorized 

293 disclosure or modification. 

294 Provide ongoing support for information sharing activities. 

295 Each organization should establish an information sharing plan that provides for ongoing infrastructure 

296 maintenance and user support. The plan should address the collection and analysis of threat information 

297 from both internal and external sources and the use of this information in the development and 

298 deployment of protective measures. A sustainable approach is necessary to ensure that resources are 

299 available for the ongoing collection, storage, analysis, and dissemination of cyber threat information. 

300 
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301 


1. Introduction 


302 1.1 Purpose and Scope 


303 This publication provides guidance to help organizations exchange cyber threat information. The 

304 guidance addresses consuming and using cyber threat information received from external sources and 

305 producing cyber threat information that can be shared with other organizations. The document also 

306 presents specific considerations for participation in information sharing communities. 


307 This publication expands upon the information sharing concepts introduced in Section 4, Coordination 

308 and Information Sharing, of NIST Special Publication (SP) 800-61, Computer Security Incident Handling 

309 Guide [1], 


310 1.2 Audience 


311 This publication is intended for computer security incident response teams (CSIRTs), system and network 

312 administrators, security staff, privacy officers, technical support staff, chief information security officers 

313 (CISOs), chief information officers (CIOs), computer security program managers, and others who are key 

314 stakeholders in cyber threat information sharing activities. 

315 Although this guidance is written primarily for Federal agencies, it is intended to be applicable to a wide 

316 variety of other governmental and non-governmental organizations. 

317 1.3 Document Structure 


318 The remainder of this document is organized into the following sections and appendices: 

319 • Section 2 introduces basic cyber threat information sharing concepts, describes the benefits of sharing 

320 information, and discusses the challenges faced by organizations as they implement sharing 

321 capabilities. 

322 • Section 3 provides guidelines on establishing sharing relationships with other organizations. 

323 • Section 4 discusses considerations for participating in sharing relationships. 

324 • Appendix A contains scenarios that show how sharing cyber threat information increases the 

325 efficiency and effectiveness of the organizations involved and enhances their network defenses by 

326 leveraging the cyber experience and capabilities of their partners. 

327 • Appendix B contains a list of terms used in the document and their associated definitions. 

328 • Appendix C provides a list of acronyms used in the document. 

329 • Appendix D identifies resources referenced in the document. 
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2. Basics of Cyber Threat Information Sharing 


332 This section introduces basic concepts of cyber threat information sharing. It discusses types of cyber 

333 threat information and defines common terminology. It also examines potential uses for shared cyber 

334 threat information and explores benefits and challenges of threat information sharing. 

335 2.1 Threat Information Types 

336 A cyber threat is “any circumstance or event with the potential to adversely impact organizational 

337 operations (including mission, functions, image, or reputation), organizational assets, individuals, other 

338 organizations, or the Nation through an information system via unauthorized access, destruction, 

339 disclosure, or modification of information, and/or denial of service.” [2] For brevity, this publication uses 

340 the term threat instead of “cyber threat”. The individuals and groups posing threats are known as “threat 

341 actors” or simply actors. 

342 Threat information is any information related to a threat that might help an organization protect itself 

343 against a threat or detect the activities of an actor. Major types of threat information include the 

344 following: 

345 • Indicators are technical artifacts or observables 1 that suggest an attack is imminent or is currently 

346 underway, or that a compromise may have already occurred. Examples of indicators include the 

347 Internet Protocol (IP) address of a suspected command and control server, a suspicious Domain Name 

348 System (DNS) domain name, a Uniform Resource Locator (URL) that references malicious content, a 

349 file hash for a malicious executable, or the subject line text of a malicious email message. 

350 • Tactics, techniques, and procedures (TTPs) describe the behavior of an actor. Tactics are high-level 

351 descriptions of behavior, techniques are detailed descriptions of behavior in the context of a tactic, 

352 and procedures are even lower-level, highly detailed descriptions in the context of a technique. TTPs 

353 could describe an actor’s tendency to use a specific malware variant, order of operations, attack tool, 

354 delivery mechanism (e.g., phishing or watering hole attack), or exploit. 

355 • Security alerts , also known as advisories, bulletins, and vulnerability notes, are brief, usually human- 

356 readable, technical notifications regarding current vulnerabilities, exploits, and other security issues. 

357 Security alerts originate from sources such as the United States Computer Emergency Readiness 

358 Team (US-CERT), Information Sharing and Analysis Centers (ISACs), the National Vulnerability 

359 Database (NVD), Product Security Incident Response Teams (PSIRTs), commercial security service 

360 providers, and security researchers. 

361 • Threat intelligence reports are generally prose documents that describe TTPs, actors, types of 

362 systems and information being targeted, and other threat-related information that provides greater 

363 situational awareness to an organization. Threat intelligence is threat information that has been 

364 aggregated, transformed, analyzed, interpreted, or enriched to provide the necessary context for 

365 decision-making processes. 

366 • Tool configurations are recommendations for setting up and using tools (mechanisms) that support 

367 the automated collection, exchange, processing, analysis, and use of threat information. For example, 

368 tool configuration information could consist of instructions on how to install and use a rootkit 

369 detection and removal utility, or how to create and customize intrusion detection signatures, router 

370 access control lists (ACLs), firewall rules, or web filter configuration files. 


1 An observable is an event (benign or malicious) on a network or system. 
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371 Many organizations already produce and share threat information internally. For example, an 

372 organization’s security team may identify malicious files on a compromised system when responding to 

373 an incident and produce an associated set of indicators (e.g., file names, sizes, hash values). These 

374 indicators are then shared with system administrators who configure security tools, such as host-based 

375 intrusion detection systems, to detect the presence of these indicators on other systems. Likewise, the 

376 security team may launch an email security awareness campaign in response to an observed rise in 

377 phishing attacks within the organization. These practices demonstrate information sharing within an 

378 organization. 

379 The primary goal of this publication is to foster similar threat information sharing practices across 

380 organizational boundaries - both acquiring threat information from other organizations, and providing 

381 internally-generated threat information to other organizations. 

382 2.2 Benefits of Information Sharing 

383 Threat information sharing provides access to threat information that might otherwise be unavailable to an 

384 organization. Using shared resources, organizations are able to enhance their security posture by 

385 leveraging the knowledge, experience, and capabilities of their partners in a proactive way. Allowing 

386 “one organization’s detection to become another’s prevention” 2 is a powerful paradigm that can advance 

387 the overall security of organizations that actively share. 

388 An organization can use shared threat information in many ways. Some uses are operationally oriented, 

389 such as updating enterprise security controls for continuous monitoring with new indicators and 

390 configurations so they can detect the latest attacks and compromises. Others are strategically oriented, 

391 such as using shared threat information as inputs when planning major changes to an organization’s 

392 security architecture. 

393 Threat information exchanged within communities organized around industrial sector (or some other 

394 shared characteristic) can be particularly beneficial because the member organizations often face actors 

395 that use common TTPs that target the same types of systems and information. Cyber defense is most 

396 effective when organizations collaborate successfully to deter and defend against well-organized, capable 

397 actors. By working together, organizations can also build and sustain the trusted relationships that are the 

398 foundation of secure, responsible, and effective information sharing. 

399 Benefits of information sharing include: 

400 • Shared Situational Awareness. Information sharing enables organizations to leverage the collective 

401 knowledge, experiences, and analytic capabilities of their sharing partners within a community of 

402 interest, thereby enhancing the defensive capabilities of multiple organizations. Even a single 

403 contribution—a new indicator or observation about a threat actor—can increase the awareness and 

404 security of an entire community. 

405 • Enhanced Threat Understanding. By developing and sharing threat information, organizations gain 

406 a better understanding of the threat environment and are able to use threat information to inform their 

407 cybersecurity and risk management practices. Using shared information, organizations are able to 

408 identify affected platforms or systems, implement protective measures, enhance detection capabilities, 

409 and more effectively respond and recover from incidents based on observed changes in the current 

410 threat environment. 


2 This phrase, which has been used in numerous presentations and discussions, was formulated by Tony Sager, Senior VP and 
Chief Evangelist, Center for Internet Security. 
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411 • Knowledge Maturation. When seemingly unrelated observations are shared and analyzed by 

412 organizations, they can be correlated with data collected by others. This enrichment process increases 

413 the value of information by enhancing existing indicators and by developing knowledge of threat 

414 actor TTPs that are associated with a specific incident, threat, or threat campaign. Correlation can also 

415 impart valuable insights into the relationships that exist between indicators. 

416 • Herd Immunity. The principle of herd or community immunity comes from biology, where it refers 

417 to protecting a community from a disease by vaccinating many, but not all, of its members. Similarly, 

418 organizations that act upon the threat information they receive by remediating threats to themselves 

419 afford a degree of protection to those who are yet unprotected (i.e., who have either not received or 

420 acted upon the threat information received) by reducing the number of viable attack vectors for threat 

421 actors, thus reducing vulnerability. 

422 • Greater Defensive Agility. Actors continually adapt their TTPs to attempt to evade detection, 

423 circumvent security controls, and exploit new vulnerabilities. Organizations that share information are 

424 often better informed about changing TTPs and can rapidly detect and respond to threats, thereby 

425 reducing the probability of successful attack. Such agility creates economies of scale for network 

426 defenders while increasing the costs of actors by forcing them to develop new TTPs. 

427 2.3 Challenges to Information Sharing 

428 While there are clear benefits to sharing threat information, there are also a number of challenges to 

429 consider. Some challenges that apply both to consuming and to producing threat information are: 

430 • Establishing Trust. Trust relationships form the basis for information sharing, but require effort to 

431 establish and maintain. Ongoing communication through regular in-person meetings, phone calls, or 

432 social media can help accelerate the process of building trust. 

433 • Achieving Interoperability. Standardized data formats and transport protocols are important 

434 building blocks for interoperability and help enable the secure, automated exchange of structured 

435 threat information among organizations, repositories, and tools. Adopting specific formats and 

436 protocols, however, can require significant time and resources, and the value of these investments can 

437 be substantially reduced if sharing partners require different formats or protocols. 

438 • Protecting Sensitive but Unclassified Information. Disclosure of sensitive information, such as 

439 personally identifiable information (PII), intellectual property, trade secrets, or other proprietary 

440 information can result in financial loss, violation of sharing agreements, legal action, and loss of 

441 reputation. Sharing information could expose the protective or detective capabilities of the 

442 organization and result in threat shifting by the actor. 3 The unauthorized disclosure of information 

443 may impede or disrupt an ongoing investigation, jeopardize information needed for future legal 

444 proceedings, or disrupt response actions such as botnet takedown operations. Organizations should 

445 apply handling designations to shared information and implement policies, procedures, and technical 

446 controls to actively manage the risks of disclosure of sensitive but unclassified information. 


3 NIST SP 800-30, Guide for Conducting Risk Assessments [2], defines threat shifting as “the response of adversaries to 
perceived safeguards and/or countermeasures (i.e., security controls), in which adversaries change some characteristic of their 
intent/targeting in order to avoid and/or overcome those safeguards/counteimeasures. Threat shifting can occur in one or more 
domains including: (i) the time domain (e.g., a delay in an attack or illegal entry to conduct additional surveillance); (ii) the target 
domain (e.g., selecting a different target that is not as well protected); (iii) the resource domain (e.g., adding resources to the 
attack in order to reduce uncertainty or overcome safeguards and/or countermeasures); or (iv) the attack planning/attack method 
domain (e.g., changing the attack weapon or attack path).” 
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447 • Protecting Classified Information. Information received from government sources may be marked 

448 as classified, making it difficult for an organization to use. It is also expensive and time-consuming 

449 for organizations to request and maintain the clearances needed for ongoing access to classified 

450 information sources. In addition, many organizations employ non-U.S. citizens who are not eligible to 

451 hold security clearances and are not permitted access to classified information. [3] 

452 Some challenges to information sharing apply only to consuming others’ threat information: 

453 • Accessing External Information. Organizations need the infrastructure to access external sources 

454 and incorporate the information retrieved from external sources into local decision-making processes. 

455 Information received from external sources has value only to the extent that an organization is 

456 equipped to act on the information. 

457 • Evaluating the Quality of Received Information. Before an organization takes security-relevant 

458 actions (such as reconfiguring protection devices) based on information received from an information 

459 sharing community, an organization needs to validate that the received information addresses an 

460 identified need, and that the costs or risks of using the information are understood. 

461 Several challenges are only applicable if an organization wants to provide its own information to other 

462 organizations: 

463 • Complying with Legal and Organizational Requirements. An organization’s executive and legal 

464 teams may restrict the types of information that the organization can provide to others. Such 

465 restrictions may include limits on the types of information and the level of technical detail provided. 

466 These safeguards are appropriate when they address legitimate business, legal, or privacy concerns, 

467 but the imposition of unwarranted or arbitrary restrictions may diminish the utility, availability, 

468 quality, and timeliness of shared information. 

469 • Limiting Attribution. Organizations may openly participate in information sharing communities, but 

470 still require that their contributions remain anonymous. Sharing unattributed information may allow 

471 organizations to share more information while controlling risks to an organization’s reputation. The 

472 lack of attribution may, however, limit the usefulness of the information because users may have less 

473 confidence in information that originates from an unknown source. If the original sources of 

474 information cannot be identified, organizations may be unable to confirm that information has been 

475 received from multiple independent sources, and thus reduce an organization’s ability to build 

476 confidence in received information. 

477 • Enabling Information Production. Organizations seeking to produce information should have the 

478 necessary infrastructure, tools, and training to do so, commensurate with the types of information to 

479 be produced. While basic threat information (e.g., indicators) is relatively easy to collect and publish, 

480 information such as an actor’s motives and TTPs generally requires greater analysis effort. 
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481 


3. Establishing Sharing Relationships 


482 When launching a threat information sharing capability, the following planning and preparation activities 

483 are recommended: 4 


484 • Define the goals and objectives of information sharing (section 3.1) 

485 • Identify internal sources of threat information (section 3.2) 

486 • Define the scope of information sharing activities (section 3.3) 

487 • Establish information sharing rules (section 3.4) 

488 • Join a sharing community (section 3.5) 

489 • Plan to provide ongoing support for information sharing activities (section 3.6) 

490 Throughout this process, organizations are encouraged to consult with subject matter experts both inside 

491 and outside their organization. Such sources include: 

492 • Experienced cybersecurity personnel 

493 • Members and operators of established threat information sharing organizations 

494 • Trusted business associates, supply chain partners, and industry peers 

495 • Personnel knowledgeable about legal issues, internal business processes, procedures, and systems 

496 An organization should use the knowledge and experience from these experts to help shape a threat 

497 information sharing capability that supports its mission and operates in accordance with its security, 

498 privacy, regulatory, and legal compliance requirements. Due to constantly changing risks, requirements, 

499 priorities, technology, and/or regulations, this process will often be iterative. Organizations should 

500 reassess and adjust their information sharing capabilities as needed based on changing circumstances. 

501 Such a change may involve repeating some or all of the planning and preparation activities listed above. 

502 3.1 Define Information Sharing Goals and Objectives 

503 At the outset, an organization should establish goals and objectives that describe the desired outcomes of 

504 threat information sharing in terms of the organization’s business processes and security policies. These 

505 goals and objectives will help guide the organization through the process of scoping its information 

506 sharing efforts, selecting and joining sharing communities, and providing ongoing support for information 

507 sharing activities. Due to technological and/or resource constraints, it may be necessary to prioritize goals 

508 and objectives to ensure the most critical ones are addressed. 

509 3.2 Identify Internal Sources of Cyber Threat Information 

510 A key step in any information sharing effort is to identify potential sources of threat information within an 

511 organization. Sources of threat information include sensors, tools, data feeds, and information 

512 repositories. Specific steps that may be helpful are: 


4 

Although an order for these activities is described, in practice the sequence of these activities can vary, and activities can even 
be performed concurrently. For example, when joining an established sharing organization, it may make sense to address 
information sharing rules as part of joining the community. 


9 




NIST SP 800-150 (2 nd DRAFT) 


Guide to Cyber Threat Information Sharing 


513 • Identify sensors, tools, data feeds, and repositories that produce threat information, and confirm that 

514 they produce the information with sufficient frequency, precision, and accuracy to support 

515 cybersecurity decision-making 

516 • Identify threat information that is collected and analyzed as part of an organization’s continuous 

517 monitoring strategy 

518 • Locate threat information that is collected and stored, but not necessarily analyzed or reviewed on an 

519 ongoing basis (e.g., operating system default audit log files) 

520 • Identify threat information that is suitable for sharing with outside parties and that could help them 

521 more effectively respond to cyber threats 

522 This inventory process also includes identifying the owners and operators of threat information sources 

523 within an organization. Ideally, personnel would possess an in-depth knowledge of the sensors, tools, data 

524 feeds, and repositories that they operate and be able to contribute to the process of developing data export, 

525 transformation, and integration capabilities in support of information sharing initiatives. When developing 

526 such capabilities, it is important to understand how the information is natively stored; what formats are 

527 available for data export; and which query languages, protocols, and services are available to interact with 

528 the information source. Some sources may store and publish structured, machine-readable data, while 

529 others may provide unstructured data with no fixed format (e.g., free text or images). Structured data 

530 based on open, machine-readable, standard formats can generally be more readily accessed, searched, and 

531 analyzed by a wider range of tools. Thus, the format of the information plays a significant role in 

532 determining the ease and efficiency of information use, analysis, and exchange. 

533 During the inventory process, an organization should also take note of any information gaps that may 

534 prevent realization of the organization’s goals and objectives. By identifying these gaps, an organization 

535 will be better able to prioritize investments into new capabilities, and identify opportunities to fill gaps by 

536 acquiring threat information from alternate, possibly external, sources or through the deployment of 

537 additional tools or sensors. 

538 Table 3-1 describes common sources of cybersecurity-related information found within organizations and 

539 provides examples of data elements from these sources that may be of interest to security operations 

540 personnel. 

541 Table 3-1: Selected Internal Information Sources 


Source 

Examples 

Network Data Sources 

Router, firewall, remote services 
(such as remote login or remote 
command execution), and 

Dynamic Host Configuration 
Protocol (DHCP) server logs 

Timestamp 

Source and destination IP address 

TCP/UDP port numbers 

Media Access Control (MAC) address 

Hostname 

Action (deny/allow) 

Status code 

Other protocol information 
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Source 

Examples 

Diagnostic and monitoring tools 
(network intrusion detection and 
prevention system, packet 
capture & protocol analysis) 

Timestamp 

IP address, port, and other protocol information 

Packet payloads 

Application-specific information 

Type of attack (e.g., SQL injection, buffer overflow) 

Targeted vulnerability 

Attack status (success/fail/blocked) 

Host Data Sources 

Operating system and 
application configuration settings, 
states, and logs 

Bound and established network connections and ports 

Processes and threads 

Registry settings 

Configuration file entries 

Software version and patch level information 

Hardware information 

User and groups 

File attributes (e.g., name, hash value, permissions, timestamp, size) 

File access 

System events (e.g., startup, shutdown, failures) 

Command history 

Antivirus products 

Hostname 

IP address 

MAC address 

Malware name 

Malware type (e.g., virus, hacking tool, spyware, remote access) 

File name 

File location (i.e., path) 

File hash 

Action taken (e.g., quarantine, clean, rename, delete) 

Web browsers 

Browser histories and caches including: 

• Sites visited 

• Objects downloaded 

• Objects uploaded 

• Extensions installed or enabled 

• Cookies 
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Source 

Examples 

Other Data Sources 

Security Information and Event 
Management (SIEM) 

Summary reports synthesized from a variety of data sources (e.g., 
operating system, application, and network logs) 

Email systems 

Email messages: 

Email header content 

• Sender/recipient email address 

• Subject line 

• Routing information 

Attachments 

URLs 

Embedded graphics 

Help desk ticketing systems, 
incident management/tracking 
system, and people from within 
the organization 

Analysis reports and observations regarding: 

• TTPs 

• Campaigns 

• Affiliations 

• Motives 

• Exploit code and tools 

• Response and mitigation strategies 

• Recommended courses of action 

User screen captures (e.g., error messages or dialog boxes) 

Forensic toolkits and dynamic 
and/or virtual execution 
environments 

Malware samples 

System artifacts (network, file system, memory) 


542 An organization’s inventory should be updated when new sensors, repositories, or capabilities are 

543 deployed. Additionally, significant changes to a device’s configuration, ownership, or administrative 

544 point of contact should be documented. 

545 3.3 Define the Scope of Information Sharing Activities 

546 Organizations should specify the scope of their information sharing activities by identifying the types of 

547 information available to share, the circumstances under which sharing this information is permitted, and 

548 those with whom the information can and should be shared. Organizations should review their 

549 information sharing goals and objectives while scoping information sharing activities to ensure that 

550 priorities are addressed. When defining these activities, it is important to ensure that the information 

551 sources and capabilities needed to support each activity are available. Organizations should also consider 

552 pursuing sharing activities that will address known information gaps. For example, an organization might 

553 not have an internal malware analysis capability, but it may gain access to malware indicators by 

554 participating in a sharing community. 

555 

556 The breadth of information sharing activities will vary based on an organization’s resources and abilities. 

557 By choosing a narrow scope, an organization with limited resources can focus on a smaller set of 

558 activities that provides the greatest value to the organization and its sharing partners. An organization may 

559 be able to expand the scope as additional capabilities and resources become available. Such an 

560 incremental approach helps to ensure that information sharing activities support an organization’s 

561 information sharing goals and objectives, while at the same time fitting within available resources. 

562 Organizations with greater resources and advanced capabilities may choose a larger initial scope, 

563 allowing for a broader set of activities in support of their goals and objectives. 
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564 

565 The degree of automation available to support the sharing and receipt of threat information is a factor to 

566 consider when establishing the scope of sharing activities. Less automated approaches or manual 

567 approaches, which involve humans directly in the loop, may increase human resource costs and limit the 

568 breadth and volume of information processed. The use of automation can help reduce human resource 

569 costs, allowing an organization to choose a larger scope of activities. Automated threat information 

570 sharing concepts are discussed more in section 4. 

571 

572 3.4 Establish Information Sharing Rules 

573 Before sharing threat information, it is important to: 


574 

575 

576 

577 

578 

579 

580 


• List the types of threat information that may be shared 

• Describe the conditions and circumstances when sharing is permitted 

• Identify approved recipients of threat information 

• Describe any requirements for redacting or sanitizing information to be shared 

• Specify if source attribution is permitted 

• Apply information handling designations that describe recipient obligations for protecting 
information 


581 These steps express rules that control the publication and distribution of threat information, and 

582 consequently help to prevent the dissemination of information that, if improperly disclosed, may have 

583 adverse consequences for the organization or its customers or business partners. Information sharing rules 

584 should take into consideration the trustworthiness of the recipient, the sensitivity of the shared 

585 information, and the potential impact of sharing (or not sharing). For example, an organization may 

586 express rules that limit the exchange of highly sensitive information to internal individuals or groups, that 

587 allow the sharing of moderately sensitive information with specific trusted partners, that permit 

588 information having a low sensitivity to be published within a closed sharing community, and that allow 

589 for the free exchange of non-sensitive information within public information sharing forums. 

590 

591 When establishing and reviewing information sharing rules, organizations should solicit input from their 

592 legal and privacy officials, information owners, the management team, and other key stakeholders to 

593 ensure that the sharing rules align with the organization’s documented policies and procedures. An 

594 organization may choose to codify sharing rules through Memoranda of Understanding (MOUs), Non- 

595 Disclosure Agreements (NDAs), Framework Agreements 5 , or other agreements. Organizations are 

596 encouraged to proactively establish cyber threat information sharing agreements as part of their ongoing 

597 cybersecurity operations rather than attempting to put such agreements into place while under duress in 

598 the midst of an active cyber incident. 

599 

600 An organization’s information sharing rules should be reevaluated on a regular basis. Some of the events 

601 that can trigger reevaluation are: 


5 An example of such an agreement is the Defense Industrial Base (DIB) Cyber Security/Information Assurance (CS/1A) Program 
standardized Framework Agreement [4] which implements the requirements set forth in Title 32 Code of Federal Regulations, 
Part 236, Section 236.4 through 236.6. 
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602 • Changes to regulatory or legal requirements 

603 • Updates to organizational policy 

604 • Introduction of new information sources 

605 • Risk tolerance changes 

606 • Information ownership changes 

607 • Changes in the operating/threat environment 

608 • Organizational mergers and acquisitions 

609 

610 3.4.1 Information Sensitivity and Privacy 

611 Many organizations handle information that, by regulation, law, or contractual obligation, requires 

612 protection. This includes PII and other sensitive information afforded protection under the Sarbanes- 

613 Oxley Act (SOX), the Payment Card Industry Data Security Standard (PCI DSS), the Health Information 

614 Portability and Accountability Act (HIPAA), the Federal Information Security Modernization Act of 2014 

615 (FISMA), and the Gramm-Leach-Bliley Act (GLBA). It is important for organizations to identify and 

616 appropriately protect such information. An organization’s legal team, privacy officers, auditors, and 

617 experts familiar with the various regulatory frameworks should be consulted when developing procedures 

618 for identifying and protecting sensitive information. 

619 

620 From a privacy perspective, one of the key challenges with threat information sharing is the potential for 

621 disclosure of PII 6 . Education and awareness activities are critical to ensure that individuals responsible for 

622 handling threat information understand how to recognize and safeguard PII when it is encountered. 7 

623 Internal sharing of information may result in disclosure of PII to people who, by virtue of their job 

624 functions, would not typically have routine access to such information. For example, a forensic analyst or 

625 incident responder may encounter PII while searching a hard drive for malware indicators, reviewing 

626 emails related to suspected phishing attacks, or inspecting packet captures. The analyst has a legitimate 

627 need to review this information in order to investigate an exploit, develop detection strategies, or develop 

628 defensive measures. If the result of such an analysis is shared with others, steps should be taken to protect 

629 the confidentiality of PII. 

630 An organization should have information sharing policies and procedures in place that provide guidance 

631 for the handling of PII. These policies and procedures should include steps for identifying incident data 

632 types that are likely to contain PII. Policies should describe appropriate safeguards for managing the 

633 privacy risks associated with sharing such data. A common practice is to focus on the exchange of 


6 OMB Memorandum 07-16 [5] defines PII as “information which can be used to distinguish or trace an individual’s identity, 
such as their name, social security number, biometric records, etc. alone, or when combined with other personal or identifying 
information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc. ” 
OMB Memorandum 10-22 [6] further states that “the definition of PII is not anchored to any single category of information or 
technology. Rather, it demands a case-by-case assessment of the specific risk that an individual can be identified. In performing 
this assessment, it is important for an agency to recognize that non-PII can become PII whenever additional information is made 
publicly available — in any medium and from any source — that, when combined with other available information, could be 
used to identify an individual.” NIST SP 800-122 [7] includes a slightly different definition of PII that is focused on the security 
objective of confidentiality and not privacy in the broad sense. Definitions of PII established by organizations outside of the 
federal government may vary based on the consideration of additional regulatory requirements. The guidance in this document 
applies regardless of how organizations define PII. 

7 For additional guidance and examples of privacy controls, see NIST SP 800-53, Rev 4, Appendix J, Privacy Control Catalog, 
Privacy Controls, Enhancements, and Supplemental Guidance [8]. 
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634 indicators to the maximum extent possible. Some indicators, such as file hashes, network port numbers, 

635 registry key values, and other data elements, are largely free of PII. Where PII is identified, however, 

636 organizations should redact fields containing PII that are not relevant to investigating or addressing cyber 

637 threats before sharing. 8 The type and degree of protection applied should be based on the intended use of 

638 the information, the sensitivity of the information, and the intended recipient. 

639 Where practical, organizations are encouraged to use automated methods rather than human-oriented 

640 methods to identify and protect PII. Manual identification, extraction, and obfuscation of PII can be a 

641 slow, error-prone, and resource-intensive process. Automated methods may include checking the contents 

642 of data fields against a list of permitted values, searching for PII using pattern matching techniques such 

643 as regular expressions, and performing operations that de-identify, mask, and anonymize data containing 

644 PII. The degree of automation that can be achieved will vary based on factors such as the structure and 

645 complexity of the data, the sensitivity of the information, and the capabilities of the tools being used. 

646 Organizations should also implement safeguards to protect intellectual property, trade secrets, and other 

647 proprietary information from unauthorized disclosure. The disclosure of such information could result in 

648 financial loss, violate NDAs or other sharing agreements, be cause for legal action, or damage an 

649 organization’s reputation. 

650 Table 3-2 introduces selected types of threat information, provides examples of sensitive data that may be 

651 present in these types of threat information, and offers general recommendations for handling such data 

652 when it is encountered. 

653 Table 3-2: Handling Recommendations for Selected Types of Sensitive Data 


Type of Threat 
Information 

Examples of Sensitive Data 
Elements 9 

Recommendations 

Network 

Any single network indicator can be 

Focus on the exchange of network indicators 

Indicators 

sensitive, but network indicators in the 

such as destination IP addresses associated with 


aggregate are often more sensitive 

a threat actor’s command and control 


because they can reveal relationships 

infrastructure, malicious URLs/domains, and 


between network entities. By studying 
these relationships it may be possible 

staging servers. 


to infer the identity of users, gather 

Before sharing, anonymize or sanitize network 


information about the posture of 

indicators that contain IP or MAC addresses of 


devices, perform network 

target systems or addresses registered to your 


reconnaissance, and characterize the 

organization. Also anonymize or sanitize 


security safeguards and tools that an 

indicators that may reveal the structure of internal 


organization employs. 

networks, or ports or protocols that identify 
particular products. 


s NIST SP 800-122 [7] describes a process called “de-identification” which entails the removal or obfuscation of PII, such that 
the remaining information cannot be used to identify an individual. 

9 The PII confidentiality impact level as discussed in NIST SP 800-122 [7] is a useful tool for gauging sensitivity of PII. 
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Type of Threat 
Information 

Examples of Sensitive Data 
Elements 9 

Recommendations 

Packet Capture 
(PCAP) 

In addition to the network indicators 
previously discussed, unencrypted or 
decrypted packets may contain 
authentication credentials and 
sensitive organization information, 
such as Pll and intellectual property. 

PCAP files can be challenging because network 
indicators may be present within both the packet 
header and the payload. For example, PCAP files 
may show protocols (e.g., DFICP, Address 
Resolution Protocol (ARP), File Transfer Protocol 
(FTP), DNS) and applications operating at 
multiple layers within the network stack. These 
protocols and applications generate network 
information that may be captured within PCAP 
files and may require sanitization or 
anonymization to prevent sensitive information 
leakage. 

Filter PCAP files before sharing by extracting 
only those packets that are related to the 
investigation of a specific incident or pattern of 
events: 

• Related to a particular network 
conversation (i.e., exchange of 
information between specific IP 
addresses of interest) 

• Occurring during a designated time 
period 

• Destined for, or originating from, a 
specific port 

• Employing a particular network protocol 

Redact payload content that contains Pll or other 
sensitive information or that is not relevant for 
characterizing the incident or event of interest. 

When anonymizing or redacting network 
information, it is important to use a strategy that 
preserves enough information to support 
meaningful analysis of the resulting PCAP file 
contents. 

Network Flow 
Data 

Network flow data contains information 
such as: 

• Source IP address (i.e., the 
sender) 

• Destination IP address (i.e., 
the recipient) 

• Port and protocol information 

• Byte counts 

• Timestamps 

If not effectively anonymized, network 
flow data may make identification of 
specific users possible, provide 
insights into user behavior (e.g., web 
sites visited), expose application and 
service usage patterns, or reveal 
network routing information and data 
volumes. 

Before sharing network flow data, organizations 
should consider redacting portions of session 
histories using cryptography-based, prefix¬ 
preserving, IP address anonymization techniques 
to prevent network identification or to conceal 
specific fields within the session trace (e.g., time 
stamps, ports, protocols, or byte counts). To gain 
the greatest value from the information, it is 
important to use a tool that transforms network 
flow data without breaking referential integrity. 
Network flow analysis and correlation operations 
often require that IP address replacement and 
transformation operations are performed 
consistently within and sometimes across 
multiple files. Anonymization techniques that do 
not employ a consistent replacement strategy 
may reduce or eliminate the value of sharing this 
type of information. 
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Type of Threat 
Information 

Examples of Sensitive Data 
Elements 9 

Recommendations 

Phishing Email 
Samples 

Email headers may contain 
information such as: 

• Mail agent IP addresses 

• Host or domain names 

• Email addresses 

An email message body may also 
contain Pll or other types of sensitive 
information. 

Organizations should anonymize email samples 
and remove any sensitive information that is not 
necessary for describing an incident or event of 
interest. 

System, 

Network, and 
Application 

Logs 

Log files may contain Pll or other 
types of sensitive information. Log 
data may reveal IP addresses, ports, 
protocols, services, and URLs, as well 
as connection strings, logon 
credentials, portions of financial 
transactions, or other activities 
captured in URL parameters. 

Organizations should perform IP address, 
timestamp, port, and protocol anonymization and 
remove any sensitive information that is not 
necessary for describing an incident or event of 
interest. Before sharing log data, it may also be 
necessary to sanitize URLs that contain 
identifying information such as session or user 

IDs. Application logs may require redaction and 
anonymizing operations that are specific to 
particular application log formats. 

Malware 
Indicators and 
Samples 

Although organizations are unlikely to 
encounter Pll in malware indicators or 
samples, it is possible that Pll or other 
sensitive information may be present 
depending on how targeted the 
malware is and what collection 
methods were used to gather a 
sample. 

Organizations should remove Pll or other 
sensitive information that is not necessary for 
describing an incident or event of interest. 


654 

655 3.4.2 Sharing Designations 

656 A variety of methods exist to designate handling requirements for shared threat information. These 

657 designations identify unclassified information that may not be suitable for public release and that may 

658 require special handling. A designation applied to threat information can communicate specific handling 

659 requirements and identify data elements that are considered sensitive and should be redacted prior to 

660 sharing. Organizations are encouraged to provide clear handling guidance for any shared threat 

661 information. Likewise, recipients of threat information should observe the handling, attribution, 

662 dissemination, and storage requirements expressed in the source organization’s handling guidance. 

663 The Traffic Light Protocol (TLP), depicted in Table 3-3, provides a framework for expressing sharing 

664 designations. [9] 

665 


17 





666 

667 

668 

669 

670 

671 

672 

673 

674 

675 

676 

677 

678 

679 

680 

681 

682 

683 

684 

685 

686 

687 

688 

689 

690 

691 

692 

693 


NIST SP 800-150 (2 nd DRAFT) 


Guide to Cyber Threat Information Sharing 


Table 3-3: Traffic Light Protocol 


Color 

When should it be used? 

How may it be shared? 


Sources may use TLP:RED when information 
cannot be effectively acted upon by additional 
parties, and could lead to impacts on a party's 
privacy, reputation, or operations if misused. 

Recipients may not share TLP:RED information 
with any parties outside of the specific 
exchange, meeting, or conversation in which 
it is originally disclosed. 

AMBER 

Sources may use TLP:AMBER when information 
requires support to be effectively acted upon, but 
carries risks to privacy, reputation, or operations if 
shared outside of the organizations involved. 

Recipients may only share TLP:AMBER 
information with members of their own 
organization who need to know, and only as 
widely as necessary to act on that 
information. 

GREEN 

Sources may use TLP:GREEN when information is 
useful for the awareness of all participating 
organizations as well as with peers within the 
broader community or sector. 

Recipients may share TLP:GREEN information 
with peers and partner organizations within 
their sector or community, but not via publicly 
accessible channels. 

WHITE 

Sources may use TLP:WHITE when information 
carries minimal or no foreseeable risk of misuse, in 
accordance with applicable rules and procedures 
for public release. 

TLP:WHITE information may be distributed 
without restriction, subject to copyright 
controls. 


The TLP specifies a color-coded set of restrictions that indicate which restrictions apply to a particular 
record. In the TLP, red specifies the most restrictive rule, with information sharable only in a particular 
exchange or meeting, not even within a participant’s own organization. The amber, green, and white color 
codes specify successively relaxed restrictions. 

The Anti-Phishing Working Group (APWG) has also proposed a schema for expressing sharing 
designations [10]. The APWG schema describes an extensible, hierarchical tagging system that can be 
used to express distribution restrictions on shared information. The tags can be used to indicate with 
whom the information may or may not be shared (e.g., recipient only, with affected parties only, no 
restrictions) and to express other caveats (e.g., that no attribution is permitted). 

For some threat information, collection methods may be considered confidential or proprietary, but the 
actual indicators observed may be shareable. In such cases, an organization may want to use tear line 
reporting, an approach where reports are organized such that information of differing sensitivity is not 
intermingled (e.g., the indicator information is presented in a separate part of the document than the 
collection methods). Organizing a report in this manner allows an organization to readily produce a report 
containing only information that designated recipients are authorized to receive. 

An organization should carefully choose, or formulate, an approach for expressing sharing designations. 
Regardless of how an organization expresses sharing designations, it should ensure that the procedures for 
applying designations to threat information are documented and approved, and that the personnel 
responsible for assigning such designations are appropriately trained. 

3.4.3 Cyber Threat Information Sharing and Tracking Procedures 

Over time, an organization’s cybersecurity activities can result in the accumulation of large quantities of 
threat information from various sources, both internal and external. Though challenging, tracking of data 
sources is important both for protecting information owners and for ensuring that consuming 
organizations are able to meet their legal or regulatory commitments for data protection. Additionally, 
preserving the provenance of data is important for analytic purposes to yield insights into who provided 
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694 the information and how the information was collected, transformed, or processed. This kind of 

695 information is important for drawing conclusions from shared information. 

696 An organization should formulate procedures that allow prompt sharing of threat information while at the 

697 same satisfying its obligations for protecting potentially sensitive data. The procedures should, to the 

698 extent possible, balance the risks of possibly ineffective sharing against the risks of possibly flawed 

699 protection. An organization’s information sharing and tracking procedures should: 

700 • Identify threat information that can be readily shared with trusted parties. 

701 • Establish processes for reviewing, sanitizing, and protecting threat information that is likely to 

702 contain sensitive information. 

703 • Automate the processing and exchange of threat information where possible. 

704 • Describe how information handling designations are applied, monitored, and enforced. 

705 • Accommodate non-attributed information exchange, when needed. 

706 • Track internal and external sources of threat information. 

707 The procedures should enumerate the roles, responsibilities, and authorities (both scope and duration) of 

708 all stakeholders. The procedures should allow for the effective transfer of authority and flow of shared 

709 information to key decision makers and should enable collaboration with approved external communities 

710 when needed. 

711 3.5 Join a Sharing Community 

712 When evaluating potential sharing partners, an organization should look to sources that complement its 

713 existing threat information resources or that offer actionable information that addresses known gaps in an 

714 organization’s situational awareness. Since sharing communities may focus on the exchange of a specific 

715 type of cyber threat information, an organization may need to participate in multiple information sharing 

716 forums to meet its information sharing objectives. 

717 Threat information can be acquired from public and private sharing communities, government 

718 repositories, commercial cyber threat intelligence feeds, and open sources. Sharing communities often 

719 organize around a shared characteristic or interest. The composition of a community may be based on 

720 geographic region, political boundary, industrial sector, business interest, or threat space (e.g., focused on 

721 phishing attacks). Many of these communities have multinational constituencies and global reach. 

722 Examples of potential sharing partners are ISACs, domestic and foreign Computer Emergency Readiness 

723 Teams (CERTs) or CSIRTs, threat and vulnerability repositories, law enforcement agencies, product 

724 vendors, managed security service providers, internet service providers, supply chain partners, industry 

725 sector peers, business partners, and customers. 

726 Some communities are informal, open, self-organizing groups that largely operate through voluntary 

727 cooperation. The membership of these communities is often mutable (i.e., no formal fixed membership), 

728 sometimes anonymous, and the members may maintain full autonomy with minimal central coordination. 

729 These communities generally operate under basic rules of conduct rather than formal agreements. In such 

730 communities, members publish threat information to the community on a voluntary, ad hoc basis and are 

731 individually responsible for ensuring that the content that they provide to the community is suitable for 

732 sharing. Organizations wishing to consume information can subscribe to or access various delivery 

733 mechanisms offered by a community such as web services, email or text alerts, and RSS feeds. Such 

734 sharing communities generally make no assertions regarding the quality and accuracy of data provided by 
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735 their members, and the degree to which the information should be trusted depends on the reputation of 

736 submitters (if known). 

737 In contrast, formal sharing communities may define specific membership rules such as: 


738 • Eligibility requirements for institutions (e.g., must operate within a specific industry sector) 

739 • Eligibility requirements for individuals (e.g., must have enterprise-wide security responsibilities) 

740 • Nomination or sponsorship requirements (i.e., brokered trust) 

741 • Probationary membership period requirements 

742 • Membership fee structures 

743 • Types of threat information the community provides/accepts 

744 • Standard delivery mechanisms, formats, and protocols supported by the community 

745 • Required organizational cybersecurity capabilities 

746 Formal communities may recruit members by invitation or through sponsorship, and, as such, members 

747 are vetted. Membership rosters in formal communities are generally more stable than those of informal 

748 communities. The exchange of information in a formal community is often governed through service 

749 level agreements (SLAs), NDAs, and other agreements that enumerate the responsibilities of its members 

750 and participating organizations. Some communities collect an annual membership fee to cover the 

751 services and administrative costs of the community. These fees vary by community and the fee structure 

752 is sometimes tiered, providing for different levels of membership and service. 

753 Before entering into information sharing agreements, it is important to obtain approval from an 

754 organization’s: 


755 

756 

757 

758 

759 

760 

761 

762 

763 

764 

765 

766 

767 

768 

769 


• Leadership team that is responsible for oversight over information sharing activities and for 
controlling the resources necessary to support the organization’s information sharing goals 

• Legal team or those with the authority to enter into commitments 

• Privacy officers and other key stakeholders that have a role in the collection, ingest, storage, analysis, 
publication, or protection of threat information 

When choosing a sharing community, consideration should be given to the types of information that are 

shared within the community, the structure and dynamics of the community, and the cost of entry and 

sustainment of membership. When evaluating how information is shared within a community, an 

organization should consider the following questions: 

• Is the threat information shared within the community relevant and does it complement existing threat 
information by providing meaningful insights in the context of an organization’s threat environment? 

• Is the threat information exchanged within the community actionable? 

• Does the community have mechanisms in place to accept non-attributed cyber threat submissions and 
the ability to protect a submitter’s identity? 

• Is the disseminated threat information timely, reliable, and of known good quality? 
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770 • Are the information exchange formats used by the community compatible with the infrastructure and 

771 tools used in an organization? 

772 • Given the frequency and volume of data disseminated by a community, does an organization have the 

773 capacity to ingest/analyze/store the information? 

774 In addition to the information shared within a community, consideration should also be given to the 

775 dynamics of the community and its participants, including: 

776 • What is the size and composition of the community? (e.g., number of participants, information 

777 producers, and information consumers) 

778 • How active is the community? (e.g., number of submissions or requests per day) 

779 • Are community members recruited and vetted? If so, how? 

780 • What are the technical skills and proficiencies of the community members? 

781 • What is the community’s governance model? 

782 • What are the initial and sustained costs of membership? 

783 • What type of sharing agreement does the community use? 

784 • Is the sharing agreement well-aligned with an organization’s goals, objectives, and business rules? 

785 When researching sharing communities, organizations are encouraged to have conversations with current 

786 or former members regarding their experiences as a participant in a community. Such conversation can 

787 provide additional insight and help an organization assess the trustworthiness of a prospective 

788 community. 

789 3.6 Plan to Provide Ongoing Support for Information Sharing Activities 

790 To ensure that information sharing activities have ongoing support, organizations should establish a plan 

791 that outlines how their information sharing infrastructure will be maintained, and how its users will be 

792 supported. The plan should identify the supporting personnel, infrastructure, and processes needed to: 

793 • Collect and analyze the information from both internal and external sources 

794 • Acquire and deploy protective measures 

795 • Acquire and deploy a monitoring and threat detection infrastructure 

796 It is important to ensure that sufficient funding exists for the personnel, infrastructure, and training 

797 required for ongoing operational support for data collection, storage, analysis, and dissemination; for 

798 technology refreshment; and for membership or service fees required for community participation. 

799 Although participation in information sharing activities will require ongoing funding, effective use of 

800 threat information may avoid the potentially much larger costs of successful attacks. 
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801 


4. Participating in Sharing Relationships 


802 An organization’s participation in an information sharing community will typically include some or all of 

803 the following activities: 


804 • Engage in ongoing communication (section 4.1) 

805 • Consume and respond to security alerts (section 4.2) 

806 • Consume and use indicators (section 4.3) 

807 • Organize and store indicators (section 4.4) 

808 • Produce and publish indicators (section 4.5) 

809 The following sections describe these activities in greater detail. Organizations just starting their threat 

810 information sharing efforts should initially choose one or two activities to focus on and should consider 

811 adding additional activities as their information sharing capability matures. Regardless of an 

812 organization’s information sharing maturity, it is important to understand that information sharing should 

813 augment, but not replace, an organization’s fundamental cybersecurity capabilities. 

814 4.1 Engage in Ongoing Communication 


815 Information sharing communities use a variety of communications methods to share threat information 

816 with their members. Most organizations are able to receive threat information via email lists, text alerts, 

817 and web portals without infrastructure investments specific to information sharing, although the content 

818 received through these delivery channels may need to be manually processed (e.g., “cut and paste” into 

819 tools). For recipients that have security tools that support standard data formats, the use of standards- 

820 based data feeds can enable semi-automated ingest, processing, and use of threat information. Other 

821 information sharing methods, such as conferences and workshops, require dedicated staff and travel. 

822 Organizations that actively produce and share threat information are likely to incur higher communication 

823 costs. Communications may be event-driven (i.e., in response to the actions or behavior of an actor) or 

824 periodic, such as bi-weekly reviews, teleconferences, and annual conferences. 


825 The level of detail, volume, and frequency of messages delivered in human-readable formats varies 

826 widely across information sharing communities. Some communities seek to deliver the most current 

827 threat information with minimal latency. In contrast, some recipients using threat information for trending 

828 and analysis may prefer summary data and may have no need for near real-time delivery of detailed 

829 information. To reduce the number of messages generated, sharing communities sometimes provide the 

830 option of subscribing to digests (i.e., compilations of messages over time intervals) rather than receiving 

831 individual messages. 


832 An organization that has recently joined an information sharing community may require time to integrate 

833 new threat information sources into its existing cybersecurity practices, configure security tools, and train 

834 decision makers on how to interpret and act upon the threat information. During this ramp-up period, an 

835 organization should consult any best practices guidance offered by a community, observe and learn from 

836 the interactions of more experienced members, and query community support resources (e.g., community 

837 knowledgebase, FAQs, blogs). Community-sponsored training events also provide opportunities for less 

838 mature organizations and inexperienced employees to gain practical insights from skilled practitioners. 

839 Organizations should also establish recruitment and retention processes that reduce personnel turnover 

840 and foster the formation of trusted professional relationships between sharing communities and 

841 organizations. Retention of skilled staff mitigates the loss of institutional knowledge, and preserves 

842 investments in training. 
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843 Ongoing participation in a sharing community is essential for fostering stronger ties to other members and 

844 continuously improving practices. Organizations that actively participate in community-sponsored 

845 conference calls and face-to-face meetings are better able to establish trust with other members and 

846 consequently to effectively collaborate over time. 

847 4.2 Consume and Respond to Security Alerts 

848 An information sharing community may publish security alerts notifying community members of 

849 emerging vulnerabilities, exploits, and other security issues. Fields that commonly appear in security 

850 alerts such as US-CERT alerts, NVD vulnerability advisories, and vendor security bulletins include 10 : 

851 • Brief overview/executive summary and detailed description, which would include indicators 

852 • Platforms affected (e.g., operating system, application, hardware) 

853 • Estimated impact (e.g., system crash, data exfiltration, application hijacking) * 11 

854 • Severity rating (e.g., Common Vulnerability Scoring System (CVSS) [11]) 

855 • Mitigation options, including permanent fixes and/or temporary workarounds 

856 • References for more information 

857 • Alert metadata (e.g., alert creation and modification dates, acknowledgments) 

858 Upon receipt of a security alert, an organization should first determine if the alert came from a trusted, 

859 reliable source. When alerts originate from unknown or untrusted sources, it may be necessary to subject 

860 them to additional scrutiny and/or seek independent confirmation before taking action. If an alert is 

861 deemed credible, an organization should determine if it owns or operates any of the affected systems, 

862 applications, or hardware identified in the alert; if so, the organization should craft an appropriate 

863 response. 

864 When crafting a response, an organization should characterize the overall impact of an alert by assessing 

865 factors such as the severity of the alert, the number of affected systems within the organization, the effects 

866 an attack might have on the organization’s mission-critical functions, and the operational impact of 

867 deploying mitigating security controls. This assessment should inform the prioritization and approach for 

868 response actions. Response actions include activities such as identifying and extracting indicators from an 

869 alert, using indicators to develop and deploy detection signatures, making configuration changes, 

870 applying patches, notifying personnel of threats, and implementing or enhancing security controls. The 

871 indicator extraction and response actions are largely manual processes today but there are clear incentives 

872 for automating these activities. Manual processing of indicators can be time-consuming, tedious, error- 

873 prone, and slow; automation of the activities allows analysts to focus on the interpretation of information, 

874 rather than routine data manipulations. 

875 4.3 Consume and Use Indicators 

876 The consumption and use of indicators from external feeds is often a multi-step process that includes 

877 some, if not all, of the following activities: 


10 Source: United States Computer Emergency Readiness Team (US-CERT) 

11 A more extensive list of potential effects is given in the MITRE Common Weakness Enumeration ( http://cwe.mitre.org/) and 
Common Vulnerabilities and Exposures ( http://cve.mitre.org/ ) listings. 
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878 • Validation: verifying the integrity of indicator content and provenance through the use of digital 

879 signatures, cryptographic hashes, or other means. 

880 • Decryption: transforming encrypted indicator files or data streams back to their original format. 

881 • Decompression: unpacking compressed indicator files, archive files (e.g., zip, tar), or data streams. 

882 • Prioritization: processing indicators based on relative importance, the perceived value of a data 

883 source, the overall confidence in the data, any operational requirements that specify that data sources 

884 be processed in a particular order, the amount of effort required to transform the data into actionable 

885 information, or other factors. 

886 • Content extraction: parsing indicator files and extracting indicator information of interest to an 

887 organization. 

888 • Categorization: reviewing indicator metadata to determine its security designation and handling 

889 requirements. Sensitive information may require encrypted storage, more stringent access control, or 

890 limitations on distribution. Content like malware samples may require special handling precautions to 

891 prevent inadvertent introduction of malicious code onto production networks. 

892 These activities are typically performed in the order described above, but the order may vary based on 

893 specific operational or security requirements. Where feasible, organizations are encouraged to automate 

894 these activities to expedite use of indicators and minimize manual effort. In cases where indicators are 

895 being informally shared, such as through email, indicator prioritization and categorization are still 

896 important and should be performed by the recipient. 

897 Ideally, indicators are: 

898 • Timely. Indicators that are delivered with minimal latency maximize the time recipients have to 

899 prepare suitable responses. The time criticality of indicators depends on the characteristics of the 

900 threats, including their severity, speed, and ease of propagation, the infrastructure being targeted, the 

901 TTPs being employed, and the capabilities of the actor (or actors). Some decision cycles may require 

902 that indicators be delivered within seconds or minutes to counter a fast-moving actor; other threats 

903 may effectively be addressed using indicators that are hours, days, or even months old. 

904 • Relevant. Indicators that are applicable to a recipient’s operating environment and that address 

905 threats the organization is likely to face are much more useful to recipients and allow them to more 

906 effectively analyze risks associated with particular threats. 

907 • Accurate. Indicators that are correct, complete, and unambiguous are most useful. Inaccurate or 

908 incomplete information introduces uncertainty and may prevent critical action, stimulate unnecessary 

909 action, result in ineffective responses, or instill a false sense of security. 

910 • Specific. Indicators should provide clear descriptions of observable events that recipients can use to 

911 detect threats while minimizing false positives/negatives. 

912 • Actionable. Indicators should provide sufficient information and context to allow recipients to 

913 develop a suitable response. 

914 In practice, an indicator may exhibit some, but not all, of these characteristics. For example, indicators 

915 might not be actionable because the recipient has no means of detection, information is missing, or the 

916 threat has changed. However, this does not mean that such indicators are of no value to an organization. 
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917 Such indicators can be enriched through aggregation, correlation with other threat information, and 

918 additional analysis. As indicators mature, it is important for organizations to share any new insights so 

919 that an entire community may benefit. 

920 Organizations may use externally and internally-generated indicators in a variety of ways, e.g., to: 

921 • Reconfigure firewalls, intrusion detection systems, data loss prevention systems, and/or other security 

922 controls to block or alert on activity matching the indicators (for example, connections involving IP 

923 addresses on a blacklist) 

924 • Configure security information and event management solutions or other log management-related 

925 systems to help with analysis of security log data 

926 • Scan security logs, systems, or other sources of information, using indicators as search keys, to 

927 identify systems that may have already been compromised 

928 • Find matching records when investigating an incident or potential incident to learn more about a 

929 threat, and to help expedite incident response and recovery actions 

930 • Inform human security analyses 

931 • Educate staff on threat characteristics 

932 • Identify threat trends that may necessitate long-term changes to security controls 

933 Typically, an organization’s willingness to use indicators from external sources is strongly affected by the 

934 level of trust the organization has in the. Indicators received from a trusted source might be put to 

935 immediate use to detect and respond to a threat. In contrast, indicators originating from an untrusted 

936 source may require independent validation, additional research, or testing before use. Indicator use might 

937 also be affected by other factors, such as an organization’s tolerance for service disruptions. For some 

938 organizations, security is paramount and occasionally blocking benign activity is considered acceptable. 

939 For other organizations, service availability may be so important that possibly malicious activity might 

940 only trigger monitoring. 

941 An organization should carefully consider the characteristics of indicators that it receives and should take 

942 a risk-based approach to determining how indicators can be most effectively used. An organization may 

943 find that a specific indicator is useful in some situations but not in others. Ultimately it is up to each 

944 organization to decide how to best use indicators. 

945 4.4 Organize and Store Indicators 

946 Organizations may collect indicators from a variety of sources, including open source repositories, 

947 commercial threat feeds, and external partners. Depending on how indicators are being used, there may be 

948 a need to organize them in a knowledgebase. Free-form methods such as wikis can be quite flexible and 

949 suitable for developing working notes and indicator metadata. Structured databases are also useful for 

950 storing, organizing, tracking, querying, and analyzing collections of indicators. 

951 Information commonly recorded in a knowledgebase includes the following, when known: 

952 • Source of an indicator 

953 • Rules governing the use of, or sharing of, an indicator 
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954 • Date or time an indicator was collected 

955 • How long an indicator is valid 

956 • Whether or not attacks associated with an indicator have targeted specific organizations or sectors 

957 • Any Common Vulnerability Enumeration (CVE), Common Configuration Enumeration (CCE), or 

958 Common Weakness Enumeration (CWE) records associated with an indicator 

959 • Groups or actors associated with an indicator 

960 • Aliases of any associated actors 

961 • TTPs commonly used by an actor 

962 • Motives or intent of an associated actor 

963 • Employees or types of employees targeted in associated attacks 

964 • Systems targeted in attacks 

965 An indicator knowledgebase is an attractive target and may well become a target of attack. Therefore, 

966 measures should be taken to ensure that appropriate security practices are followed for a knowledgebase, 

967 such as restricting access to authorized personnel only, backing up the knowledgebase regularly, 

968 maintaining the knowledgebase systems’ operating systems and applications with current patches and 

969 secure configurations, and following software development best practices for the production of any in- 

970 house software used for the knowledgebase. 12 

971 Organizations should establish policies and procedures that address the disposition of indicators (and 

972 threat information in general). Policies and procedures should define data retention requirements for short 

973 (online) and long (offline) term availability of indicator information. Information handling and retention 

974 requirements may change once threat information is entered into evidence. Evidence acquired during any 

975 incident investigations, for instance, should be collected and preserved using best practices for data 

976 preservation following chain of custody requirements and other laws pertaining to the submission of 

977 evidence. A more detailed treatment of forensic techniques related to chain of custody and preserving 

978 information integrity is available in NIST SP 800-86 [12] and Section 3.3.2 of NIST SP 800-61 Revision 

979 2 [1], 

980 For indicators that are not needed as evidence, organizations should determine appropriate retention 

981 policies. 13 Although retaining threat information has costs, detailed information may provide historical 

982 value as well as help new sharing community members and partners understand the persistence and 

983 evolution of different actors and attack types. Other considerations, such as financial, legal, contractual, 

984 or regulatory issues, may limit data retention to a fixed period of months or years. Once a retention 

985 schedule is identified, organizations should either archive or destroy the indicators in accordance with 

986 applicable policies. 14 

987 


12 The NIST Software Assurance Metrics and Tool Evaluation (SAMATE) project seeks to develop standard evaluation measures 
and methods for software assurance. http://samate.nist.gov/index.php/SAMATE Publications.html 

13 Federal agencies are subject to the National Archives and Records Administration (NARA) General Records Schedule as well 
as agency-specific retention policies. 

14 NIST SP 800-88 [13] provides guidance to assist organizations in making risk-based decisions regarding the sanitization and 
disposition of media and information. 
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988 4.5 Produce and Publish Indicators 

989 Many organizations only consume indicators. However, some organizations, often those with more 

990 advanced security capabilities, choose to produce and publish their own indicators. An organization may 

991 benefit substantially by producing threat information. For example, an organization may gain greater 

992 expertise, help other organizations more effectively respond to threats in their environments, and foster 

993 trust with other community members. These effects are important for building and sustaining the flow of 

994 threat information that ultimately benefits a producing organization. A producer of shared threat 

995 information must decide what, if any, metadata should accompany shared information, what data formats 

996 should be used, how sensitive data should be handled, and how information sharing rules should be 

997 maintained over time. The following subsections address these issues. 

998 4.5.1 Indicator Enrichment 

999 When producing and publishing indicators, it is important to include metadata that provides context for 

1000 each indicator, describing how it is to be used and interpreted and how it relates to other indicators. 

1001 Metadata may also include sensitivity designations and provenance information (e.g., what tool was used 

1002 to acquire the data, how the data was processed, who collected the data). As indicators are created, 

1003 aggregated, or enriched, their sensitivity and classification should be reevaluated. An aggregation, 

1004 association, or enrichment process may enable re-identification (e.g., using data mining techniques) or 

1005 elevate the sensitivity of the information, thus necessitating additional data handling restrictions. 

1006 The indicator production process should provide a mechanism for publishing indicators, updating 

1007 indicators and associated metadata, and retracting submissions that are incorrect or perhaps inadvertently 

1008 shared. Any automated mechanisms should be hardened and tested to ensure that they do not become 

1009 viable attack vectors for threat actors. Organizations that share indicators should provide a feedback 

1010 mechanism that allows sharing partners to submit error reports, suggest improvements, or request 

1011 additional information about the indicators. Such feedback plays an important role in the enrichment, 

1012 maturation, and quality of the indicators shared within a community. 

1013 Some information shared within a community may be marked as “currently under investigation” and may 

1014 require that members avoid sharing beyond the collective; such markings may also prohibit members 

1015 from performing active information collection (such as retrieving malware samples from a suspect 

1016 website, or performing DNS lookups on suspect hostnames) that might tip off a potential actor or 

1017 otherwise compromise investigative activities. At some point, such information will probably have its 

1018 distribution and investigation restrictions downgraded, so it is useful to have a mechanism to change the 

1019 marking or to add a revised marking such as “downgraded to GREEN as of 12/20/2015.” 

1020 4.5.2 Standard Data Formats 

1021 The use of standard data formats for the exchange of indicators enhances interoperability and allows 

1022 information to be exchanged with greater speed. Unstructured formats (e.g., text documents, email) are 

1023 suitable for high-level threat reports and ad hoc exchanges of indicator information and other materials 

1024 intended to be read by security personnel rather than machines. For time-critical exchanges of indicators, 

1025 however, such as automatically configuring a firewall to block specified communications, the use of 

1026 standard data formats is encouraged because they minimize the need for human assistance. When 

1027 evaluating standard formats for data exchange, choose formats that are widely adopted, readily extensible 

1028 (i.e., new data elements or features can be incorporated with minimal engineering and design effort), and 

1029 scalable, and that provide the requisite data security features. 
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1030 4.5.3 Protection of Sensitive Data 

1031 The indicators that an organization publishes may be sensitive, so it is important to prevent their 

1032 unauthorized disclosure or modification. Indicator data can be protected using a variety of methods, 

1033 including encrypted network communications, authentication and authorization mechanisms, and storage 

1034 in a hardened repository. If a repository is used, an organization should have a written SLA for the 

1035 repository that specifies expected availability, security posture requirements, and acceptable use policies. 

1036 When producing indicators that may contain sensitive information, appropriate sharing rules (see section 

1037 3.4) should be followed, and information should be shared only with community members that are trusted 

1038 to follow sharing rules and that have agreed to do so. 
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1039 


Appendix A—Cyber Threat Information Sharing Scenarios 


1040 This appendix presents a number of scenarios that describe threat information sharing in real-world 

1041 applications. These scenarios seek to show how sharing and coordination can increase the efficiency and 

1042 effectiveness of an organization’s cybersecurity capabilities. These scenarios represent only a small 

1043 number of the possible applications of information sharing and collaboration. 


1044 Scenario 1: Nation-State Attacks against a Specific Industry Sector 

1045 

1046 A nation-state regularly targets companies in a certain industry sector over several months. The attacks 

1047 come in the form of targeted emails that carry malicious attachments containing a software exploit that, 

1048 upon opening, launches malware on a victim’s system. Systems that are successfully compromised by the 

1049 malware are then reconfigured by the malware to contact command and control servers and other 

1050 infrastructure operated by the threat actor to receive additional instructions, to download additional 

1051 malware, and to exfiltrate data. 


1052 Many companies within this industry sector participate in a formal threat information sharing 

1053 organization in which a central forum is used to post information about observed threats. The posts 

1054 describe details relevant to detecting and defending against the threat, such as the sender addresses of 

1055 phishing emails, samples of malware collected from the attacks, analysis of exploit code used by the 

1056 attackers, the IPs and URLs associated with the attacker’s command and control servers, and other 

1057 infrastructure involved with attacks. 


1058 As soon as one company’s security team identifies a new attack, the information is shared with its peers 

1059 within the forum. One of the companies (A) that participates in the forum has advanced malware analysis 

1060 capabilities and is able to further characterize the threat actor and its command and control infrastructure 

1061 using a malware sample shared via the forum by another company (B). Company A then shares back the 

1062 information gained through its analysis of the malware. Through B’s sharing of the malware sample, the 

1063 community benefits from the malware analysis capabilities of company A, and is able to quickly and 

1064 efficiently detect and protect against similar attacks against their organizations. In this scenario, an attack 

1065 faced by one company contributes to another’s defense. 

1066 Scenario 2: Campaign Analysis 

1067 

1068 Cybersecurity analysts from companies in a business sector have been sharing indicators and malware 

1069 samples in an online forum over the past few years. Each company performs independent analysis of the 

1070 attacks and observes consistent patterns over time, with groups of events often having a number of 

1071 commonalities, such as the type of malware used, the DNS domains of command and control channels, 

1072 and other technical indicators. These observations lead the analysts to suspect that the attacks are not fully 

1073 random, but part of a larger coordinated set of actions. 

1074 The forum members participate in technical exchange meetings to share data, insights, and analyses of the 

1075 different attacks. Through data aggregation and joint analyses, the members are able to identify activities 

1076 that are likely attributable to a common threat actor or to coordination among threat actors. This scenario 

1077 demonstrates how data fusion and analysis may help reveal collective action and campaigns by a threat 

1078 actor and identify the TTPs that are used by specific threat actors as part of a campaign. 

1079 Scenario 3: Distributed Denial of Service Attack against an Industry Sector 

1080 

1081 A hacktivist group targets a select set of companies for a large-scale distributed denial of service (DDoS) 

1082 attack. The group employs a distributed botnet that is loosely coordinated and controlled by members of 
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1083 the group. By analyzing traffic generated by the botnet, one of the companies targeted in the attack is able 

1084 to determine that the attackers are using a variant of a popular DDoS tool. 

1085 The targeted companies are members of an ISAC and use the ISAC’s discussion portal to establish a 

1086 working group to coordinate their efforts to end the attack. The working group contacts the ISAC’s law 

1087 enforcement liaison, who coordinates with federal and international authorities to aid in the investigation 

1088 and to gain court orders to shut down the attacker systems. 

1089 The working group contacts various internet service providers (ISPs), and provides information to aid in 

1090 identifying abnormal traffic to their network addresses. The ISPs assist both the affected companies and 

1091 law enforcement personnel by helping to identify the upstream and downstream traffic sources, 

1092 implementing routing changes, and enforcing data rate limits on these sources. Using network traffic 

1093 collected by the ISPs, law enforcement agencies are able to identify the command and control servers, 

1094 seize these assets, and identify some members of the hacktivist group. 

1095 After a technical exchange meeting among the targeted companies, several companies decide to enlist the 

1096 aid of content distribution providers to distribute their web presences and make their business systems 

1097 more resilient to future DDoS attacks. 

1098 Scenario 4: Financial Conference Phishing Attack 

1099 

1100 A cyber crime group makes use of a publicly available conference attendee list to target specific 

1101 individuals with a wave of phishing emails. The group is able to identify attendees who are members of 

1102 the target organization’s corporate accounting team (i.e., individuals who may have the authority to 

1103 authorize payments or funds transfers). Through the use of targeted malware, distributed through phishing 

1104 attacks, the group attempts to compromise machines and accounts to complete unauthorized electronic 

1105 payments and funds transfers to overseas businesses. 

1106 One company is able to identify the phishing attack against personnel within its corporate accounting 

1107 team and learns, during their investigation, that all the recipients targeted during the attack had attended 

1108 the same conference six months earlier. The company’s CSIRT contacts the conference organizers, as 

1109 well as representatives from other organizations that attended the conference. The affected organizations 

1110 arrange a conference call to share specific information (e.g., email header content, attachments, embedded 

1111 URLs) regarding the attacks. Using the shared indicators, other conference attendees review their mail 

1112 and network traffic logs to identify potentially compromised hosts. These companies agree to ongoing 

1113 collaboration and information sharing about future attacks via an informal email list. 

1114 Scenario 5: Business Partner Compromise 

1115 

1116 “Company A” and “Company B” are business partners that have established network connectivity 

1117 between their organizations to facilitate the exchange of business information. A cyber crime organization 

1118 compromises a server at Company B and uses that access as a stepping stone to launch attacks against 

1119 internal servers at Company A. Operations personnel at Company A notice the unusual activity and notify 

1120 their security team. The security team identifies the source of the activity as coming from a Company B 

1121 system. As stipulated in their business partner connectivity agreement, Company A notifies Company B 

1122 about the anomalous traffic and the companies initiate a joint response to the incident following 

1123 established procedures. Company A’s incident response team describes the activity it is seeing, allowing 

1124 Company B’s team to isolate the compromised server and perform an investigation to identify the source 

1125 of the breach and other possible compromises. Their investigation reveals that the attackers exploited a 

1126 software flaw in a web-facing application and used it to gain unauthorized access to the server. The 

1127 application development team at Company B implements and deploys a code change to close the security 
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1128 hole, and the security operations team enables additional logging and intrusion detection signatures to 

1129 identify any similar future attacks. 

1130 Because the security teams of the two companies had agreements and processes in place for a joint 

1131 response, had pre-established contacts and existing trust relationships, and had already understood each 

1132 other’s networks and operations, they were able to quickly respond and recover from the incident. 

1133 Scenario 6: US-CERT Provides Indicators, Receives Feedback 

1134 

1135 The US-CERT receives information, from a variety of independent sources, that a number of servers 

1136 located in the U.S. are being used to carry out cyber attacks against other U.S. companies. A specific 

1137 foreign actor is known to control the compromised servers. The US-CERT identifies the targeted 

1138 companies and notes that they are predominantly from the aviation industry. The US-CERT contacts the 

1139 security teams of these companies and shares initial threat information, including URLs, malware, and 

1140 vulnerabilities being exploited by the threat actor. 

1141 Using the indicators, a number of affected companies are able to detect attacks against their 

1142 infrastructures and to take the actions necessary to prevent the attacks from being successful. During their 

1143 investigation, the affected companies are also able to identify new indicators or provide additional context 

1144 regarding the attack to the US-CERT. The US-CERT is able to share these new indicators with other 

1145 firms after anonymizing the sources, which leads to a more comprehensive response to the threat. 

1146 Scenario 7: A Retailer Fails to Share 

1147 A large retailer is subject to a cyber attack by a criminal organization. Millions of credit card numbers and 

1148 account information are stolen during a breach that goes undiscovered for several weeks. The retailer does 

1149 not participate in sharing threat information, so the organization relies on its own security and detection 

1150 capabilities. Its internal capabilities prove inadequate in the face of a sophisticated, targeted threat that 

1151 uses custom malware. 

1152 The breach is discovered by credit card companies investigating a rash of credit card fraud. The 

1153 commonality in the credit card fraud was purchases made from this one retailer. The credit card 

1154 companies notify law enforcement and the retailer, which begins an investigation. 

1155 The damages are extensive. The company notifies its customers of the theft of personal information, but 

1156 does not release details of how the attack was carried out. Consequently, several other retailers are 

1157 successfully attacked using the same methods in the weeks following the initial breach. The financial 

1158 losses realized by the retailers, customers, and credit card issuers could have been avoided, at least in part, 

1159 had these companies engaged in active sharing of threat information with one another. 


31 



NIST SP 800-150 (2 nd DRAFT) 


Guide to Cyber Threat Information Sharing 


1160 


Appendix B—Glossary 


1161 


Selected terms used in the publication are defined below. 
Actor See “threat actor”. 


Alert 


Cyber Threat 
Indicator 


A brief, usually human-readable, technical notification regarding 
current vulnerabilities, exploits, and other security issues. Also 
known as an advisory, bulletin, or vulnerability note. 

See “threat”. 

A technical artifact or observable that suggests an attack is imminent 
or is currently underway, or that a compromise may have already 
occurred. 


Observable 

Tactics, Techniques, and 
Procedures (TTPs) 


Threat 


Threat Actor 
Threat Information 


Threat Intelligence 


Threat Intelligence Report 
Threat Shifting 


Tool Configuration 


An event (benign or malicious) on a network or system. 

The behavior of an actor. A tactic is the highest-level description of 
this behavior, while techniques give a more detailed description of 
behavior in the context of a tactic, and procedures an even lower- 
level, highly detailed description in the context of a technique. 

Any circumstance or event with the potential to adversely impact 
organizational operations (including mission, functions, image, or 
reputation), organizational assets, individuals, other organizations, or 
the Nation through an information system via unauthorized access, 
destruction, disclosure, or modification of information, and/or denial 
of service. [2] 

An individual or a group posing a threat. 

Any information related to a threat that might help an organization 
protect itself against a threat or detect the activities of an actor. Major 
types of threat information include indicators, TTPs, security alerts, 
threat intelligence reports, and tool configurations. 

Threat information that has been aggregated, transformed, analyzed, 
interpreted, or enriched to provide the necessary context for decision¬ 
making processes. 

A prose document that describes TTPs, actors, types of systems and 
information being targeted, and other threat-related information. 

The response of actors to perceived safeguards and/or 
countermeasures (i.e., security controls), in which actors change 
some characteristic of their intent/targeting in order to avoid and/or 
overcome those safeguards/countermeasures. [2] 

A recommendation for setting up and using tools that support the 
automated collection, exchange, processing, analysis, and use of 
threat information. 
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1 Appendix C — Acronyms 1 

Selected acronyms used 

in the publication are defined below. 

ACL 

Access Control List 

ARP 

Address Resolution Protocol 

CCE 

Common Configuration Enumeration 

CIO 

Chief Information Officer 

CISO 

Chief Information Security Officer 

CSIRT 

Computer Security Incident Response Team 

CVE 

Common Vulnerability Enumeration 

cvss 

Common Vulnerability Scoring System 

CWE 

Common Weakness Enumeration 

DDoS 

Distributed Denial of Service 

DHCP 

Dynamic Host Configuration Protocol 

DIB 

Defense Industrial Base 

DNS 

Domain Name System 

FISMA 

Federal Information Security Modernization Act 

FTP 

File Transfer Protocol 

GLBA 

Gramm-Leach-Bliley Act 

HIPAA 

Health Information Portability and Accountability Act 

IP 

Internet Protocol 

IR 

Interagency Report or Internal Report 

ISAC 

Information Sharing and Analysis Center 

ISP 

Internet Service Provider 

IT 

Information Technology 

ITL 

Information Technology Laboratory 

MAC 

Media Access Control 

MOU 

Memorandum of Understanding 

NDA 

Non-Disclosure Agreement 

NIST 

National Institute of Standards and Technology 

NVD 

National Vulnerability Database 

OMB 

Office of Management and Budget 

PCAP 

Packet Capture 

PCI DSS 

Payment Card Industry Data Security Standard 

PII 

Personally Identifiable Information 

PSIRT 

Product Security Incident Response Team 

RSS 

Rich Site Summary or Really Simple Syndication 

SIEM 

Security Information and Event Management 

SLA 

Service Level Agreement 

SOX 

Sarbanes-Oxley Act 

SP 

Special Publication 

SQL 

Structured Query Language 

TCP 

Transmission Control Protocol 

TLP 

Traffic Light Protocol 

TTP 

Tactics, Techniques, and Procedures 

UDP 

User Datagram Protocol 

URL 

Uniform Resource Locator 

US-CERT 

United States Computer Emergency Readiness Team 
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